home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 277 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  7.4 KB

  1. Path: fido.asd.sgi.com!austern
  2. From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Are all Windows programs ill-formed?
  5. Date: 05 Feb 1996 09:24:05 PST
  6. Organization: Comp Sci, University of Melbourne
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4evp66$a58@mulga.cs.mu.OZ.AU>
  9. References: <AE5J83na99@qsar.chem.msu.su> <9602010236.26117@mulga.cs.mu.OZ.AU> <9602021032.AA05302@lts.sel.alcatel.de>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: 3 Feb 1996 13:49:58 GMT
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBVAwUBMRY9QEy4NqrwXLNJAQFkwAH+IVk4uVCy/KTwNeMmEoMP5wOEyElzGLI3
  14.     853EVNRCkunRkqkn2yZ4C7Do7/6NlIQXeXwFTGi/BwBu1o/cBYG+Jg==
  15.     =dXF3
  16. Originator: austern@isolde.mti.sgi.com
  17.  
  18. James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
  19.  
  20. >fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
  21. >
  22. >|> "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
  23. >
  24. >|> The implementation is allowed to make the program work even if main() is
  25. >|> not defined, so long as it issues a diagnostic.
  26. >
  27. >By a curious coincidence, this point has just been discussed in
  28. >comp.std.c.  The concensus of the experts there was that the absense
  29. >of main (or a non-conformant main) is simply undefined behavior: no
  30. >diagnostic required.
  31.  
  32. If the comp.std.c experts are right, then I think that is a difference
  33. between C++ and C, because the September 95 draft C++ standard makes it
  34. pretty clear that a diagnostic is required.
  35.  
  36. | 3.6.1[basic.start.main]/1:
  37. |    A program shall contain a global function called main, which is the
  38. |    designated start of the program.
  39.  
  40. Here "shall" expresses a semantic requirement, and as 1.7 makes clear,
  41. a diagnostic is required:
  42.  
  43. |   1.7  Processor compliance                           [intro.compliance]
  44. | 1 Every conforming C++ processor  shall,  within  its  resource  limits,
  45. |   accept and correctly execute well-formed C++ programs, and shall issue
  46. |   at least one diagnostic message when  presented  with  any  ill-formed
  47. |   program  that contains a violation of any diagnosable semantic rule or
  48. |   of any syntax rule, except as noted herein.
  49. [...]
  50. | 3 The set of "diagnosable semantic rules" consists of all semantic rules
  51. |   in  this  International  Standard except for those rules containing an
  52. |   explicit notation that "no diagnostic is required."
  53.  
  54. James Kanze continues:
  55.  
  56. >I believe that the simple answer is that Windows programs operate in a
  57. >unhosted environment.
  58.  
  59. That's a possible answer with regard to C conformance, but C++ is different:
  60. C++ programs must contain main() even in an unhosted environment, according
  61. to the September 95 draft C++ standard.  (The reason for this is because
  62. the definition of the order of execution of constructors for global variables
  63. is defined with reference to when main() gets invoked.)
  64.  
  65. I'm not sure whether Windows C/C++ compilers claim conformance to the
  66. relevant C/C++ standards.  One would need to consult the documentation
  67. for the compiler in question to see whether they claimed conformance,
  68. and if so, whether they claimed conformance as a hosted or unhosted
  69. environment.  Even if they do claim conformance, they will usually have
  70. some conforming and some non-conforming modes of operation; you need to
  71. be sure that the compiler is being invoked in the correct mode.
  72.  
  73. >Another interesting point that was made in the discussion on
  74. >comp.std.c was that g++ normally operates in an unhosted environment,
  75. >at least according FSF.
  76.  
  77. That depends on what you mean by "normally".  If you have installed g++
  78. together with the GNU C and C++ libraries, then I believe that the FSF
  79. would claim conformance (modulo the odd bug here and there) as a hosted
  80. environment, not just as an unhosted environment.  This is normally the
  81. case on Linux, for example, although I agree that it is probably not
  82. normally the case on most other systems.
  83.  
  84. >|> You are correct to infer that this means that all Windows programs
  85. >|> which do not define main() are ill-formed.
  86. >
  87. >No, he's not.  They are simply programs for non-hosted environments.
  88.  
  89. No, I beg to differ -- as explained above, C++ requires main() even
  90. for non-hosted environemnts.
  91.  
  92. >Whether requiring a different start-up procedure than calling main is
  93. >a good idea for this extension can be discussed under quality of
  94. >implementation; it is not a standards question, however.
  95.  
  96. Actually, I think it is, albeit not a direct one. Remember that the
  97. purpose of the C++ standard is amoung other things to promote
  98. portability of C++ programs.  Extensions should be done in a way that
  99. makes it easy for customers to make selective use of them with
  100. conditional compilation, so that they can easily write portable
  101. programs that are nevertheless customized to take advantage of the
  102. features of particular platforms.  Requiring a different start-up
  103. procedure makes doing this more difficult than it need be.
  104.  
  105. >I personally think that the Microsoft environment stinks, but I still
  106. >get the feeling that there is a double standard at work here. If
  107. >someone complains that g++ doesn't issue a diagnostic when I define a
  108. >nested function, dozens of people (including you, Fergus?) will
  109. >quickly point out that all I have to do is add the flags -ansi
  110. >-pedantic, and it will; without these flags, the compiler is operating
  111. >in a non-conformant mode, and this fact is in the compiler
  112. >documentation.  Unless things have changed in the last 4 years, you
  113. >need to give a special flag to the compiler to get Windows support.
  114. >The default mode was the conformant mode.
  115.  
  116. I don't think I am applying a double standard.
  117.  
  118. I did not claim that any or all Windows compilers were not conforming.
  119. I simply pointed out what they were required to do in order to conform.
  120.  
  121. I did say that
  122.  
  123. | I think the problem is due to Microsoft overlooking the C and C++
  124. | standards, not vice versa.
  125.  
  126. but the problem I was referring to was not that Microsoft's compilers
  127. don't conform to the standard (most likely they do) but rather that
  128. Microsoft encourages people to write non-portable, non-standard-conforming
  129. code which is then subject to the usual problems of vendor lock-in.
  130.  
  131. Now GNU's compilers also have their own extensions, and the problem of
  132. vendor lock-in can also arise for programs that use GNU extensions, but
  133. I do think GNU aims to minimize the difficulty of writing portable
  134. programs that selectively take advantage of those additional features.
  135. For example, the syntax of GNU's __attribute__ feature is designed to
  136. make it easy to use a conditionally defined macro to enable/disable the
  137. use of that feature.
  138.  
  139. >|> Windows compilers which wish to conform to the C and C++ standards
  140. >|> should include code [...for WinMain()...]
  141. >|> in their libraries, so that they can accept programs which define main()
  142. >|> but not WinMain().
  143. >
  144. >And what will they do with all of the other Windows requests in the
  145. >code?
  146.  
  147. They can do whatever they like.  I was reiterating the need
  148. for Windows compilers to accept strictly conforming programs, and
  149. showing how that could easily be implemented, in a way which made the
  150. selective use of Windows features possible without the programmer
  151. having to define WinMain(), even if the OS required a program to define
  152. WinMain() rather than main().
  153.  
  154. --
  155. Fergus Henderson                 WWW: http://www.cs.mu.oz.au/~fjh
  156. fjh@cs.mu.oz.au                  PGP: finger fjh@128.250.37.3
  157. ---
  158. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  159.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  160.   in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  161.